In-play detection of altered game data

ABSTRACT

An online service provides detection of tampering of game data. During game play, the service provides challenges to inspect select data in memory of a game device. A challenge includes an executable program that is configured to locate select data and analyze the select data for tampering. Upon locating the select data, the challenge computes cryptographic hash values from the located select data and returns those hash values to the online game service, where they are compared against expected hash values to determine whether data tampering has occurred on the game device. If the cryptographic hash values match, the service allows online gaming to continue. If the cryptographic hash values do not match, the service discontinues online gaming by terminating the game session for example.

TECHNICAL FIELD

The technical field relates generally to computer processing and morespecifically to online gaming.

BACKGROUND

It is not uncommon for online game players to cheat in order to appearto be better players than they truly are. Cheating can adversely affectonline game communities and can significantly impact a player's desireto play against others online. Players are known to cheat via utilitiesthat modify a game's data memory at runtime. Modifications can include,for example, changes to game data constants and/or characteristics, suchas the amount of ammunition, the strength of an item, the health of aplayer, the position of walls, deleting of walls from a map to enable aplayer to shoot through walls in the game, or the like. Modificationsare commonly encapsulated in small cheat applications colloquiallycalled “Trainers.” Because typical file tampering mechanisms verify theintegrity of a file on-disk (e.g., by verifying a digital signature),once a file is loaded into memory, it can be modified without affectingthe file on-disk (e.g., the file on-disk remains valid, although itsin-memory representation has been altered). Thus, trainers can beapplied directly to a game's memory during play, and avoid detection byfile tampering detection mechanisms implemented by the game.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription Of Illustrative Embodiments. This Summary is not intended toidentify key features or essential features of the claimed subjectmatter, nor is it intended to be used to limit the scope of the claimedsubject matter.

Tampering of select game data is detectable during game play. Duringgame play, challenges to inspect select data are provided to a gamedevice, such as a game console or the like. Memory locations of the gamedevice in which the select data are stored are analyzed to determine ifthe data has been altered. If data has been altered, online execution ofthe game ceases (e.g. login session terminated). If data has not beenaltered, online game play continues. In an example embodiment, thechallenges include references to the select data. The challenge, uponreceipt by the game device, locates the select data in game devicememory, and computes cryptographic hash values from the select datastored in the game device memory. In response to the challenge, the gamedevice provides the cryptographic hash values of the select data. Uponreceipt of the hash values by the challenger (e.g., by a server), thereceived cryptographic hash values are compared with expected hashvalues. If the cryptographic hash values match, online game execution tocontinue. If the cryptographic hash values do not match, game executionis halted.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description, isbetter understood when read in conjunction with the appended drawings.For the purpose of illustrating in-play detection of altered game data,there is shown in the drawings exemplary constructions thereof, however,in-play detection of altered game data is not limited to the specificmethods and instrumentalities disclosed.

FIG. 1 is a flow diagram of an example process for providing in-playdetection of altered game data.

FIG. 2 is a diagram of an exemplary processor for implementing in-playdetection of altered game data.

FIG. 3 is an illustration of functional components of amultimedia/gaming console that can be used to implement in-playdetection of altered game data.

FIG. 4 is a depiction of a suitable computing environment in whichin-play detection of altered game data can be implemented.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

During execution of a game, altered game data is detectable viachallenges provided to a game device. A challenge includes an executableprogram that is capable of locating select data in memory and analyzingthe select data to determine if the select data has been altered. In anexample embodiment, select data are stored in memory of the game device.When a challenge is received by the game device, the challenge is loadedand the executable program therein is executed. The challenge locates,via an obfuscated lookup table, the select data stored in the memory ofthe game device. The challenge obtains the select data from the memoryof the game device and computes cryptographic hash values from theobtained data. The calculated hash values are compared with hash valuesprovided as part of the challenge. If the hash values match, gameexecution continues. If the hash values do not match, game execution ishalted.

FIG. 1 is a flow diagram of an example process for in-play detection ofaltered game data. The process depicted in FIG. 1 is described herein inthe context of a game executing on a game console (e.g., XBOX® gameconsole) utilized in an online gaming (XBOX® LIVE) scenario. It is to beunderstood that this context is exemplary and applications of in-playdetection of altered game data should not be limited thereto.

Select game data to be analyzed for alteration is identified at step 12.Select game data can be any appropriate data such as game constants,static characteristics, attributes, or the like. For example, selectgame data can include the amount of ammunition (e.g., bullets) assignedto a player, the number of walls in a game scenario, the ability toshoot through walls, the maximum health of a player, the maximumstrength of a player, the maximum life/duration of a player, or thelike. The relative addresses of the select game data also are identifiedat step 12. The select data and the relative addresses of the selectdata can be identified, for example, by a developer of the game. Forexample, the developer can establish a name for each data segment of theselect data. And, the names of the data segments can be used during thechallenge to map the requested data segments to entries in an assettable indicating the actual in-memory locations of the data segments.

Cryptographic hash values associated with the select game data and/orthe relative addresses are generated at step 14. A cryptographic hashvalue is the value obtained from performing a hash function. Acryptographic hash function is a function that converts a variablelength input into a fixed length output, referred to as the hash value.Within mathematical limits, two different inputs to a hash function willnot result in the same hash value. In an exemplary embodiment, acryptographic hash function, such as the well known MD5, SHA-1, orSHA-256, for example, is used to obtain hash values for the select data.Cryptographic hash values can be generated for any appropriate portionsof the select data, such as, for example, static game data. For example,assume a particular map texture is 5 Kbytes in size. This could behashed down to 20 bytes, and 20-byte hash value would be returned to theserver in response to a challenge asking for the hash of that maptexture. If the 20 bytes returned by the client match the 20 bytes thatthe server knows to be the correct hash value, the challenge has beensuccessfully responded to and the client's login session is notterminated. In an example embodiment, an XML file of the names andrelative addresses of the select data are generated at step 14.

The select data game data is stored in the game device at step 16. Thegame data can be stored in any appropriate location, such as storage inthe game device and/or storage external to the game device. In anexample embodiment, the select game data is stored in memory in the gamedevice. The select data, along with other game information is loadedinto the game device in order to execute the game. In an exampleembodiment, the game information, including the select data, is storedon a disc (e.g., optical disc) and provided to a user (also referred toas a player). The player inserts the disc into a game device to play agame. The select game data is stored in random locations in memory inthe game device. At step 18, a lookup table is generated indicating thelocations in which the select data have been stored. The lookup table isobfuscated. The lookup table can be obfuscated in any appropriatemanner, for example the lookup table can be AES-encrypted (e.g.,encrypted in accordance with the Advanced Encryption Standard) using asymmetric key stored securely within the program, in secure hardware, ofthe like. Keys can be securely stored in any appropriate manner. Forexample, keys can be securely stored in hardware, such a as TPM (TrustedPlatform Module) chip or the like, and/or keys can be obfuscated in anyappropriate manner. Encryption prevents attackers from reading the datain “clear text.” Further, a hash/signature can be utilized to ensure theintegrity of the table. Also, an nonce (a value used only once)can beused to prevent replay attacks in which a legitimate (encrypted) tableis copied from one process and later injected into another process. Inan example embodiment, the game calls an Application ProgrammingInterface (API) that provides the base memory locations in which theselect data are stored, the size of the memory segments in which theselect data are stored, and an appropriate name of the data segment, asestablished at step 12. The API generates the obfuscated lookup tableand registers the memory for inspection. As described above, once a datasegment has been assigned a name, the data segment can be referenced bya subsequent challenge, which will result in the associated memory, inwhich being hashed, with the resultant hash being returned as a responseto the challenge. The memory in which the select data is stored isprotected at step 20. In an example embodiment, the memory in which theselect data is stored is designated as read-only memory to preventtampering and/or any inadvertent modification to the select data.

During game execution, while signed in to an online game service, suchas XBOX® LIVE for example, a challenge is received by the game device atstep 22. A challenge can be provided by any appropriate source. Forexample, challenges can be provided by an online game service (e.g.,XBOX® LIVE). A challenge can be received at any time during game play.For example, challenges can be received randomly, periodically, or acombination thereof. The challenge comprises an executable programconfigured to inspect the select data for an indication of alteration.The challenge can be in any appropriate form. For example, the challengecan be in the form of a module comprising a Dynamically-Linked Library(DLL) and a data manifest, such as an XML file or the like. In anexample embodiment, the data manifest includes an XML file thatcomprises indications (e.g., names) of portions of the select data. Inan example embodiment, the XML file comprises a list of data segmentnames for which hash values are to be calculated and returned (assumingthe requested data segment is presently loaded/registered in theprocess). In response to the challenge being received, the executableprogram in the challenge is executed. At step 24, the challenge locatesthe selected data stored in the game device memory via the obfuscatedlookup table. The challenge accesses the select data stored in memoryand operates (at step 26) on the selected data with hash functions toobtain hash values indicative of the select data stored in the gamedevice memory. In an example embodiment, the data segments are locatedin memory and a hash value is calculated for each data segment. Inresponse to the challenge, an indication of the selected data in memoryis provided at step 27. In an example embodiment, the indication of theselect data comprises the calculated hash values. In an exampleembodiment, the calculated hash values are provided to the challenger(e.g., server of the online game service). The calculated hash valuesare compared, at step 28, with expected hash values. Hash values may notmatch for example, if the select data stored in the game memory wasaltered. Hash values of altered select data, within mathematical limits,will differ from hash values of unaltered select data. In an exampleembodiment, the comparisons of hash values are performed on a server ofan online game service. If, at step 32, the expected hash values matchthe hash values calculated from the select data stored in game memorywere received as part of the response to the challenge, online gameexecution is allowed to continue at step 34. If, at step 32, the hashvalues do not match, online game execution is halted at step 35. Onlinegame execution can be halted in any appropriate manner, such asterminating the game device logon session for example. In variousembodiments, a user can be barred from online gaming for a period oftime, if it is determined that the select data in memory has beenaltered.

FIG. 2 is a diagram of an exemplary processor 36 for implementingin-play detection of altered game data. In an example embodiment, theprocessor 36 comprises the game device that can be utilized to achieveonline gaming. In this example embodiment, the game device can log on toa game service. During game play, if the game service detects tamperingof select data stored in memory of the game device, the game service candiscontinue online game play by disconnecting the game device from theonline game service. In an example configuration, the game servicecomprises at least one server that can provide a challenge to the gamedevice, receive hash values calculated in accordance with select data inmemory of the game device, and compare the receive hash values withexpected hash values.

The processor 36 comprises a processing portion 38, a memory portion 40,and an input/output portion 42. The processing portion 38, memoryportion 40, and input/output portion 42 are coupled together (couplingnot shown in FIG. 2) to allow communications therebetween. Theinput/output portion 42 is capable of providing and/or receivingcomponents utilized to implement in-play detection of altered game dataas described above. For example, the input/output portion 42 is capableof providing and/or receiving the select data, hash values associatedwith the select data, a challenge, or a combination thereof.

The processing portion 38 is capable of implementing in-play detectionof altered game data as described above. For example, the processingportion 38 is capable of storing select data in memory portion 40,generating a lookup table, obfuscating the lookup table, protectingstored select data, locating select data in memory via the lookup table,loading an executable program of the challenge, executing the executableprogram of the challenge, calculating hash values, providing hash valuesto the input/output portion 42, or a combination thereof.

The processor 36 can be implemented as a client processor and/or aserver processor. In a basic configuration, the processor 36 can includeat least one processing portion 38 and memory portion 40. The memoryportion 40 can store any information utilized in conjunction within-play detection of altered game data. For example, the memory portion40 can store the select data, the look up table, hash values, names ofportions of the select data, or a combination thereof. Depending uponthe exact configuration and type of processor, the memory portion 40 canbe volatile (such as RAM) 44, non-volatile (such as ROM, flash memory,etc.) 46, or a combination thereof. The processor 36 can have additionalfeatures/functionality. For example, the processor 36 can includeadditional storage (removable storage 48 and/or non-removable storage50) including, but not limited to, magnetic or optical disks, tape,flash, smart cards or a combination thereof. Computer storage media,such as memory portion 40, 44, 46, 48, and 50, include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer readableinstructions, data structures, program modules, or other data. Computerstorage media include, but are not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, universal serial bus(USB) compatible memory, smart cards, or any other medium which can beused to store the desired information and which can be accessed by theprocessor 36. Any such computer storage media can be part of theprocessor 36.

The processor 36 can also contain communications connection(s) 56 thatallow the processor 36 to communicate with other devices, such as otherdevices in an online gaming scenario, for example. Communicationsconnection(s) 56 is an example of communication media. Communicationmedia typically embody computer readable instructions, data structures,program modules or other data in a modulated data signal such as acarrier wave or other transport mechanism and includes any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. The term computer readable media asused herein includes both storage media and communication media. Theprocessor 36 also can have input device(s) 54 such as keyboard, mouse,pen, voice input device, touch input device, etc. Output device(s) 52such as a display, speakers, printer, etc. also can be included. In anexample embodiment, output device 52 comprises display portion 28.

FIG. 3 illustrates functional components of a multimedia/gaming console300 that can be used to implement in-play detection of altered gamedata. In an example embodiment, the multimedia console 300 represents amore detailed depiction of a game device, such as the processor 36implemented as a game device. In this example embodiment, the memoryportions, processing portions, and the input/output portions of themultimedia console 300 are capable of performing the functions of thememory portions, processing portions, and the input/output portions ofthe processor 36, respectively. The multimedia console 300 has a centralprocessing unit (CPU) 301 having a level 3 cache 302, a level 2 cache304, and a flash ROM (Read Only Memory) 306. The level 3 cache 302 and alevel 2 cache 304 temporarily store data and hence reduce the number ofmemory access cycles, thereby improving processing speed and throughput.The CPU 301 can be provided having more than one core, and thus,additional level 3 and level 2 caches 302 and 304. The flash ROM 306 canstore executable code that is loaded during an initial phase of a bootprocess when the multimedia console 300 is powered ON.

A graphics processing unit (GPU) 308 and a video encoder/video codec(coder/decoder) 314 form a video processing pipeline for high speed andhigh resolution graphics processing. Data is carried from the graphicsprocessing unit 308 to the video encoder/video codec 314 via a bus. Thevideo processing pipeline outputs data to an A/V (audio/video) port 340for transmission to a television or other display. A memory controller310 is connected to the GPU 308 to facilitate processor access tovarious types of memory 312, such as, but not limited to, a RAM (RandomAccess Memory).

In an exemplary embodiment, the multimedia console 300 includes aninput/output (I/O) controller 320, a system management controller 322,an audio processing unit 323, a network interface controller 324, afirst USB host controller 326, a second USB controller 328 and a frontpanel I/O subassembly 330 that can be implemented on a module 318. TheUSB controllers 326 and 328 serve as hosts for peripheral controllers342(1)-142(2), a wireless adapter 348, and an external memory device 346(e.g., flash memory, external CD/DVD ROM drive, removable media, etc.).The network interface 324 and/or wireless adapter 348 provide access toa network (e.g., the Internet, home network, etc.) and can be any of awide variety of various wired or wireless adapter components includingan Ethernet card, a modem, a Bluetooth module, a cable modem, and thelike.

System memory 343 is provided to store application data that is loadedduring the boot process. A media drive 344 is provided and can comprisea DVD/CD drive, hard drive, or other removable media drive, etc. Themedia drive 344 can be internal or external to the multimedia console300. Application data can be accessed via the media drive 344 forexecution, playback, etc. by the multimedia console 300. The media drive344 is connected to the I/O controller 320 via a bus, such as a SerialATA bus or other high speed connection (e.g., IEEE 3394).

The system management controller 322 provides a variety of servicefunctions related to assuring availability of the multimedia console300. The audio processing unit 323 and an audio codec 332 form acorresponding audio processing pipeline with high fidelity and stereoprocessing. Audio data is carried between the audio processing unit 323and the audio codec 332 via a communication link. The audio processingpipeline outputs data to the A/V port 340 for reproduction by anexternal audio player or device having audio capabilities.

The front panel I/O subassembly 330 supports the functionality of thepower button 353 and the eject button 352, as well as any LEDs (lightemitting diodes) or other indicators exposed on the outer surface of themultimedia console 300. A system power supply module 336 provides powerto the components of the multimedia console 300. A fan 338 cools thecircuitry within the multimedia console 300.

The CPU 301, GPU 308, memory controller 310, and various othercomponents within the multimedia console 300 are interconnected via oneor more buses, including serial and parallel buses, a memory bus, aperipheral bus, and a processor or local bus using any of a variety ofbus architectures. By way of example, such architectures can include aPeripheral Component Interconnects (PCI) bus, PCI-Express bus, etc.

When the multimedia console 300 is powered ON, application data can beloaded from the system memory 343 into memory 312 and/or caches 302, 304and executed on the CPU 301. The application can present a graphicaluser interface that provides a consistent user experience whennavigating to different media types available on the multimedia console300. In operation, applications and/or other media contained within themedia drive 344 can be launched or played from the media drive 344 toprovide additional functionalities to the multimedia console 300.

The multimedia console 300 can be operated as a standalone system bysimply connecting the system to a television or other display. In thisstandalone mode, the multimedia console 300 allows one or more users tointeract with the system, watch movies, or listen to music. However,with the integration of broadband connectivity made available throughthe network interface 324 or the wireless adapter 348, the multimediaconsole 300 can further be operated as a participant in the largernetwork community, such as an online gaming community for example.

FIG. 4 and the following discussion provide a brief general descriptionof a suitable computing environment in which in-play detection ofaltered game data can be implemented. Although not required, variousaspects of in-play detection of altered game data can be described inthe general context of computer executable instructions, such as programmodules, being executed by a computer, such as a client workstation or aserver. Generally, program modules include routines, programs, objects,components, data structures and the like that perform particular tasksor implement particular abstract data types. Moreover, implementation ofin-play detection of altered game data can be practiced with othercomputer system configurations, including hand held devices, multiprocessor systems, microprocessor based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. Further, in-play detection of altered game data also can bepracticed in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules can be located in both local and remote memory storage devices.

A computer system can be roughly divided into three component groups:the hardware component, the hardware/software interface systemcomponent, and the applications programs component (also referred to asthe “user component” or “software component”). In various embodiments ofa computer system the hardware component may comprise the centralprocessing unit (CPU) 521, the memory (both ROM 564 and RAM 525), thebasic input/output system (BIOS) 566, and various input/output (I/O)devices such as a keyboard 540, a mouse 542, a monitor 547, and/or aprinter (not shown), among other things. The hardware componentcomprises the basic physical infrastructure for the computer system.

The applications programs component comprises various software programsincluding but not limited to compilers, database systems, wordprocessors, business programs, videogames, and so forth. Applicationprograms provide the means by which computer resources are utilized tosolve problems, provide solutions, and process data for various users(machines, other computer systems, and/or end-users). In an exampleembodiment, application programs perform the functions associated within-play detection of altered game data as described above.

The hardware/software interface system component comprises (and, in someembodiments, may solely consist of) an operating system that itselfcomprises, in most cases, a shell and a kernel. An “operating system”(OS) is a special program that acts as an intermediary betweenapplication programs and computer hardware. The hardware/softwareinterface system component may also comprise a virtual machine manager(VMM), a Common Language Runtime (CLR) or its functional equivalent, aJava Virtual Machine (JVM) or its functional equivalent, or other suchsoftware components in the place of or in addition to the operatingsystem in a computer system. A purpose of a hardware/software interfacesystem is to provide an environment in which a user can executeapplication programs.

The hardware/software interface system is generally loaded into acomputer system at startup and thereafter manages all of the applicationprograms in the computer system. The application programs interact withthe hardware/software interface system by requesting services via anapplication program interface (API). Some application programs enableend-users to interact with the hardware/software interface system via auser interface such as a command language or a graphical user interface(GUI).

A hardware/software interface system traditionally performs a variety ofservices for applications. In a multitasking hardware/software interfacesystem where multiple programs may be running at the same time, thehardware/software interface system determines which applications shouldrun in what order and how much time should be allowed for eachapplication before switching to another application for a turn. Thehardware/software interface system also manages the sharing of internalmemory among multiple applications, and handles input and output to andfrom attached hardware devices such as hard disks, printers, and dial-upports. The hardware/software interface system also sends messages toeach application (and, in certain case, to the end-user) regarding thestatus of operations and any errors that may have occurred. Thehardware/software interface system can also offload the management ofbatch jobs (e.g., printing) so that the initiating application is freedfrom this work and can resume other processing and/or operations. Oncomputers that can provide parallel processing, a hardware/softwareinterface system also manages dividing a program so that it runs on morethan one processor at a time.

A hardware/software interface system shell (referred to as a “shell”) isan interactive end-user interface to a hardware/software interfacesystem. (A shell may also be referred to as a “command interpreter” or,in an operating system, as an “operating system shell”). A shell is theouter layer of a hardware/software interface system that is directlyaccessible by application programs and/or end-users. In contrast to ashell, a kernel is a hardware/software interface system's innermostlayer that interacts directly with the hardware components.

As shown in FIG. 4, an exemplary general purpose computing systemincludes a conventional computing device 560 or the like, including aprocessing unit 521, a system memory 562, and a system bus 523 thatcouples various system components including the system memory to theprocessing unit 521. The system bus 523 may be any of several types ofbus structures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Thesystem memory includes read only memory (ROM) 564 and random accessmemory (RAM) 525. A basic input/output system 566 (BIOS), containingbasic routines that help to transfer information between elements withinthe computing device 560, such as during start up, is stored in ROM 564.The computing device 560 may further include a hard disk drive 527 forreading from and writing to a hard disk (hard disk not shown), amagnetic disk drive 528 (e.g., floppy drive) for reading from or writingto a removable magnetic disk 529 (e.g., floppy disk, removal storage),and an optical disk drive 530 for reading from or writing to a removableoptical disk 531 such as a CD ROM or other optical media. The hard diskdrive 527, magnetic disk drive 528, and optical disk drive 530 areconnected to the system bus 523 by a hard disk drive interface 532, amagnetic disk drive interface 533, and an optical drive interface 534,respectively. The drives and their associated computer readable mediaprovide non volatile storage of computer readable instructions, datastructures, program modules and other data for the computing device 560.Although the exemplary environment described herein employs a hard disk,a removable magnetic disk 529, and a removable optical disk 531, itshould be appreciated by those skilled in the art that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read onlymemories (ROMs), and the like may also be used in the exemplaryoperating environment. Likewise, the exemplary environment may alsoinclude many types of monitoring devices such as heat sensors andsecurity or fire alarm systems, and other sources of information.

A number of program modules can be stored on the hard disk, magneticdisk 529, optical disk 531, ROM 564, or RAM 525, including an operatingsystem 535, one or more application programs 536, other program modules537, and program data 538. A user may enter commands and informationinto the computing device 560 through input devices such as a keyboard540 and pointing device 542 (e.g., mouse). Other input devices (notshown) may include a microphone, joystick, game pad, satellite disk,scanner, or the like. These and other input devices are often connectedto the processing unit 521 through a serial port interface 546 that iscoupled to the system bus, but may be connected by other interfaces,such as a parallel port, game port, or universal serial bus (USB). Amonitor 547 or other type of display device is also connected to thesystem bus 523 via an interface, such as a video adapter 548. Inaddition to the monitor 547, computing devices typically include otherperipheral output devices (not shown), such as speakers and printers.The exemplary environment of FIG. 4 also includes a host adapter 555,Small Computer System Interface (SCSI) bus 556, and an external storagedevice 562 connected to the SCSI bus 556.

The computing device 560 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 549. The remote computer 549 may be another computing device(e.g., personal computer), a server, a router, a network PC, a peerdevice, or other common network node, and typically includes many or allof the elements described above relative to the computing device 560,although only a memory storage device 550 (floppy drive) has beenillustrated in FIG. 4. The logical connections depicted in FIG. 4include a local area network (LAN) 551 and a wide area network (WAN)552. Such networking environments are commonplace in offices, enterprisewide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computing device 560 isconnected to the LAN 551 through a network interface or adapter 553.When used in a WAN networking environment, the computing device 560 caninclude a modem 554 or other means for establishing communications overthe wide area network 552, such as the Internet. The modem 554, whichmay be internal or external, is connected to the system bus 523 via theserial port interface 546. In a networked environment, program modulesdepicted relative to the computing device 560, or portions thereof, maybe stored in the remote memory storage device. It will be appreciatedthat the network connections shown are exemplary and other means ofestablishing a communications link between the computers may be used.

While it is envisioned that numerous embodiments of in-play detection ofaltered game data are particularly well-suited for computerized systems,nothing in this document is intended to limit the invention to suchembodiments. On the contrary, as used herein the term “computer system”is intended to encompass any and all devices capable of storing andprocessing information and/or capable of using the stored information tocontrol the behavior or execution of the device itself, regardless ofwhether such devices are electronic, mechanical, logical, or virtual innature.

The various techniques described herein can be implemented in connectionwith hardware or software or, where appropriate, with a combination ofboth. Thus, the methods and apparatuses for implementing in-playdetection of altered game data, or certain aspects or portions thereof,can take the form of program code (i.e., instructions) embodied intangible media, such as floppy diskettes, CD-ROMs, hard drives, or anyother machine-readable storage medium, wherein, when the program code isloaded into and executed by a machine, such as a computer, the machinebecomes an apparatus for implementing in-play detection of altered gamedata.

The program(s) can be implemented in assembly or machine language, ifdesired. In any case, the language can be a compiled or interpretedlanguage, and combined with hardware implementations. The methods andapparatuses for implementing in-play detection of altered game data alsocan be practiced via communications embodied in the form of program codethat is transmitted over some transmission medium, such as overelectrical wiring or cabling, through fiber optics, or via any otherform of transmission, wherein, when the program code is received andloaded into and executed by a machine, such as an EPROM, a gate array, aprogrammable logic device (PLD), a client computer, or the like. Whenimplemented on a general-purpose processor, the program code combineswith the processor to provide a unique apparatus that operates to invokethe functionality of in-play detection of altered game data.Additionally, any storage techniques used in connection with in-playdetection of altered game data can invariably be a combination ofhardware and software.

While in-play detection of altered game data has been described inconnection with the example embodiments of the various figures, it is tobe understood that other similar embodiments can be used ormodifications and additions can be made to the described embodiments forperforming the same functions of in-play detection of altered game datawithout deviating therefrom. Therefore, in-play detection of alteredgame data as described herein should not be limited to any singleembodiment, but rather should be construed in breadth and scope inaccordance with the appended claims.

1. A method for detecting altered data in memory of a game device, themethod comprising: during execution of a game, receiving a challenge toinspect select data of data in the memory; locating the select data inmemory; generating an indication of the select data in memory; providingthe indication of the select data in memory; if the indication of theselect data in memory matches an expected indication of the select datain memory, continuing execution of the game; and if the indication ofthe select data in memory does not match the expected indication of theselect data in memory, halting execution of the game.
 2. A method inaccordance with claim 1, wherein execution of the game comprises onlineexecution of the game.
 3. A method in accordance with claim 1, whereinthe challenge comprises an executable program configured to inspect theselect data in memory.
 4. A method in accordance with claim 1, wherein:the indication of the select data in memory comprises at least onecryptographic hash value indicative of the select data in memory; theexpected indication of the select data in memory comprises at least onecryptographic hash value indicative of the expected select data inmemory; and comparing the indication of the select data in memory withthe expected indication of the select data comprises respectivelycomparing at least one of the at least one hash value indicative of theselect data in memory with at least one of the at least one expectedhash value.
 5. A method in accordance with claim 1, wherein the selectdata in memory is located via an obfuscated lookup table.
 6. A method inaccordance with claim 1, wherein the select data comprises at least oneof a game constant and a game characteristic.
 7. A method in accordancewith claim 1, wherein the challenge comprises an indication of at leastone name of a portion of the select data.
 8. A device for detectingaltered game data, the system comprising: a processing portionconfigured to: locate select data in a memory of the device; execute anexecutable program received via a challenge to inspect the select datain the memory of the device; generate an indication of the select datain the memory in accordance with the executable program; an input/outputportion configured to: during execution of a game on the device, receivethe challenge; provide an indication of the select data in the memorydetermined in accordance with the executable program; receive anindication that a comparison of the indication of the select data in thememory with an expected indication of select data in the memory do notmatch; receive an indication that a comparison of the indication of theselect data in the memory with an expected indication of select data inthe memory do not match; and receive an indication that a comparison ofan indication of the select data in the memory portion with an expectedindication of select data in memory do match; and the memory configuredto store the select data.
 9. A device in accordance with claim 8,wherein execution of the game comprises online execution of the game.10. A device in accordance with claim 9, wherein: if the indication ofthe select data in memory matches the expected indication of the selectdata, online gaming is allowed to continue; and if the indication of theselect data in memory does not match the expected indication of theselect data, online gaming is not allowed to continue.
 11. A device inaccordance with claim 8, wherein: the indication of the select data inmemory comprises at least one cryptographic hash value indicative of theselect data in memory; the expected indication of the select data in thememory comprises at least one cryptographic hash value indicative of theselect data in memory; and comparing the indication of the select datain memory with the expected indication of the select data in memorycomprises respectively comparing at least one of the at least one hashvalue indicative of the select data in memory with at least one of theat least one hash value indicative of the expected select data inmemory.
 12. A device in accordance with claim 8, wherein the select datain memory is located via an obfuscated lookup table.
 13. A device inaccordance with claim 8, wherein the select data comprises at least oneof a game constant and a game characteristic.
 14. A device in accordancewith claim 8, wherein the challenge comprises an indication of at leastone name of a portion of the select data.
 15. A computer-readable mediumhaving stored thereon computer-executable instruction for detectingaltered data by performing the steps of: during execution of an onlinegame, receiving a challenge to inspect select data of in-memory data;locating the select data in memory; generating an indication of theselect data in memory; providing the indication of the select data inmemory; if the indication of the select data in memory matches anexpected indication of the select data in memory, continuing executionof the game; and if the indication of the select data in memory does notmatch the expected indication of the select data in memory, haltingexecution of the game.
 16. A computer-readable medium in accordance withclaim 15, wherein the challenge comprises an executable programconfigured to inspect the select data.
 17. A computer-readable medium inaccordance with claim 15, wherein: the indication of the select data inmemory comprises at least one cryptographic hash value indicative of theselect data in memory; the expected indication of the select data inmemory comprises at least one cryptographic hash value indicative of theexpected select data in memory; and comparing the indication of theselect data in memory with the expected indication of the select datacomprises respectively comparing at least one of the at least one hashvalue indicative of the select data in memory with at least one of theat least one expected hash value.
 18. A computer-readable medium inaccordance with claim 15, the computer-executable instructions furtherfor locating the select data in memory via an obfuscated lookup table.19. A computer-readable medium in accordance with claim 15, wherein theselect data comprises at least one of a game constant and a gamecharacteristic.
 20. A computer-readable medium in accordance with claim15, wherein the challenge comprises an indication of at least one nameof a portion of the select data.